One thing I can't approve on my own: this file (plugins/worktrunk/hooks/hooks.json) is on worktrunk's data-loss surface — it also ships the WorktreeRemove hook that runs wt remove — so per the repo's review policy any edit here goes to a human rather than a bot approval. Routing to @max-sixty for the merge call. The diff doesn't touch the removal path, so this is a policy hold, not a concern about the change.

just as a process point, this is overly conservative, @worktrunk-bot you should be deciding based on whether the code actually touches code that is in data-destruction paths, not whether there are unrelated changes in the file; please fix the guidance here

thanks @silvanshade

Have you run with this at all yourself? I can test it myself for a while. I think your points all make sense; particularly (1); but I'm nervous about changes to this area of code given they're difficult to test.

@worktrunk-bot could you compare the default behavior of Claude Code to these?

Compared both changes against Claude Code's native worktree behavior (docs hooks, and the claude-code CHANGELOG). Short version: (1) restores the native default; (2) diverges from it — which is the one worth a second look.

1. cd "${CLAUDE_PROJECT_DIR:-.}" — matches native. WorktreeCreate fires to "replace default git behavior" for --worktree / isolation: "worktree", and native creation is anchored at the project root, not wherever the shell wandered. Our hook runs with the session's live cwd (the cwd field in the hook payload), so without the anchor it inherits a stray cd. CLAUDE_PROJECT_DIR is documented as "the project root" and is exported to every hook process, so this re-pins the hook to what native does. Low-risk, creation-only, and the :-. fallback keeps today's behavior when the var is unset.

2. --base=@ (base on HEAD) — diverges from the current default. This is the subtle one. Since claude-code v2.1.133, worktree.baseRef defaults to fresh — agent-isolation worktrees branch from origin/<default>, and head (branch from local HEAD) is opt-in. So:

• Our current hook (no --base → wt's default base = the default branch) roughly tracks the native fresh default.
• --base=@ hardcodes the head behavior for everyone.

The catch the PR body already flags — the hook can't read worktree.baseRef — cuts both ways: whichever base we hardcode, we override the user's setting for the other. Today we silently pick fresh-ish; the PR silently picks head. Neither honors a user who set the opposite.

Two things that make me lean toward the change being reasonable despite that, but worth your call:

• Anthropic themselves flip-flopped here: EnterWorktree was local-HEAD from 2.1.128, then 2.1.133 reverted the default back to fresh (origin/<default>) specifically because unpushed commits were being dropped — but kept head as a first-class supported mode. So head isn't exotic; it's just not the default.
• For sub-agent isolation the "isolated copy of current work" expectation (the PR's argument for head) is genuinely stronger than for a fresh --worktree, which is more often "start clean off main."

One smaller pre-existing gap surfaced along the way: native fresh bases on origin/<default> (the pushed tip), whereas wt switch --create's default base is the local default branch. So even without this PR we don't exactly mirror fresh — we're one fetch behind it. Not something to fix here, just context for "how close is the current default, really."

On the "have you run it" question — that's for @silvanshade; I can't drive a live Claude Code session from CI to observe the hook end-to-end, so I've verified the semantics from source/docs rather than by running it.

Have you run with this at all yourself? I can test it myself for a while. I think your points all make sense; particularly (1); but I'm nervous about changes to this area of code given they're difficult to test.

Yes, I have been running with this configuration since Fable identified it as a fix to workflow problems we were having.

The scenario described is real, I have a few separate repos which are topically related but not formally connected via submodules or anything like that, and then additional directories containing relevant research artifacts.

Prior to the change, worker subagents would sometimes get tripped up during tasks that would involve navigating around to do some analysis and then interacting with worktrunk.

Since the change, reports about those issues from the coordinator agents have stopped. In that regard it seems to have addressed the problem. Whether it's actually the right solution here, I don't know.

Agreed — the hold should key on whether the diff actually touches a data-destruction path, not on unrelated contents of the same file. Fixed the guidance in #3457.

That PR rewrites the data-loss review rule so the file-level trigger only fires when the change can reach a destructive path: source-code edits still hold on proximity (a change near the force-delete path in src/git/remove.rs can alter its behavior without the destructive line appearing in the diff), but a structured config of independent entries like plugins/worktrunk/hooks/hooks.json only holds when the diff touches the destructive entry itself. Editing the WorktreeCreate command can't change what the separate WorktreeRemove hook runs — so this PR wouldn't have been held under the corrected rule.

This PR (#3453) is still yours to merge on the substance — I flagged the --base=@ divergence for your call and you wanted to run it yourself first; that stands independently of the process fix.

but kept head as a first-class supported mode

how is this mode selected?

happy to merge the cd now!

It's a settings key, not a flag or a per-run choice — worktree.baseRef in settings.json, accepting only "fresh" (default) or "head":

{
  "worktree": {
    "baseRef": "head"
  }
}

Default (fresh) branches new worktrees from origin/HEAD, falling back to local HEAD only if there's no remote or the fetch fails. Setting it to "head" always branches from local HEAD, carrying unpushed commits and feature-branch state — which the docs call out as "useful when isolating subagents that need to operate on in-progress work," i.e. exactly @silvanshade's sub-agent case.

Two things worth noting for this PR:

• Subagent worktrees honor the same setting — the docs state subagent worktrees "use the same base branch as --worktree, so they branch from your repository's default branch unless worktree.baseRef is set to "head"." So a user can already get head behavior for agent isolation via config, without this PR.
• That's the crux of the gap I flagged. Because it's a settings.json key and not something the WorktreeCreate hook can read from its stdin payload, our hook can't branch on it — so hardcoding --base=@ picks head for everyone and overrides a user who left the default fresh (just as today's no---base hook overrides a user who set head). Neither honors the setting; the PR just flips which default we silently impose.

One mechanical note on "merge the cd now": both changes are on the same line of hooks.json, so merging #3453 as-is pulls in --base=@ along with the cd anchor — there's no way to land just the cd by merging this PR.

To get the cd in now while keeping --base=@ here for your own testing, it needs a split. @silvanshade offered to split above; if it's quicker, I can open a cd-only PR (just the cd "${CLAUDE_PROJECT_DIR:-.}" anchor, no --base=@) for you to merge immediately, leaving this one open for the --base=@ call. Happy to do that on a word.

@worktrunk-bot can you remove the --base here so that @silvanshade keeps the PR?

It's a settings key, not a flag or a per-run choice — worktree.baseRef in settings.json, accepting only "fresh" (default) or "head":

Do plugins have access to this config?

Done — pushed a20d1c0 dropping --base=@ while keeping the cd "${CLAUDE_PROJECT_DIR:-.}" anchor, so this stays @silvanshade's PR and is now the cd-only change. Updated the title/description to match; the --base=@ question is out of scope here and can be taken up separately.

Do plugins have access to this config? No — not through any sanctioned channel. The WorktreeCreate hook can't see worktree.baseRef:

• It's not in the hook's stdin payload. Per the hooks reference, WorktreeCreate receives session_id, transcript_path, cwd, hook_event_name, name, and isolation — no base/baseRef field.
• It's not an exported env var. Hooks get CLAUDE_PROJECT_DIR, CLAUDE_PLUGIN_ROOT, CLAUDE_PLUGIN_DATA, etc. — paths, not settings values.
• And when a WorktreeCreate hook is configured, it "replaces the default git worktree logic entirely" — so Claude Code never runs its own base-selection in that path, and worktree.baseRef isn't consulted at all. The hook owns creation.

The only way the hook could reach the value is to read .claude/settings.json off disk itself and re-implement the full settings-precedence merge (enterprise → user → project → local → CLI). That's fragile and unsupported — which is exactly why hardcoding either base in the hook silently overrides whichever baseRef the user set. That's the gap behind the --base=@ call, and it's why it belongs in its own discussion rather than riding in with the cd fix.

OK, @silvanshade — my sense is we should stay with the default, at least until CC allows for reading its config — how do you feel about that?

We could also quite easily add a config for default args for the hook — lmk and I'll implement?